An MPEG-2 set-top-box (STB) system receives data from the outside world (i.e., broadcast programs) in the form of an MPEG-2 transport level stream. The transport stream is typically received through a transport stream interface within the set-top-box system and then parsed, demultiplexed, and routed to audio/video decoders and regions in the set-top-box system memory for further processing. The functional block within the set-top-box system that receives the transport stream data and routes selected parts of the stream to either memory, an audio decoder, or a video decoder is called a transport demultiplexor.
As more channels are added to the broadcast system, the channels may-come from different transponders. To handle multiple streams simultaneously in a set-top-box system, multiple tuners, multiple demodulators and multiple demultiplexors are conventionally needed, in addition to multiple decoders.
Thus, there is sometimes a need for a set-top-box system to be able to simultaneously receive and process selected data from multiple transport streams coming from two (or more) transponders. For example, if the application is attempting a video picture-in-picture function that involves video broadcast from two separate satellites, the set-top-box system will need to simultaneously receive video from two separate transport streams. This example can be extended to recording one program to a VCR or a hard disk drive from one transponder and viewing another program from another transponder.
Another example of simultaneous processing of two transport streams would occur during a seamless channel change to a program coming from a different transponder from a first program. If the ability to simultaneously process programs from both these transponders did not exist, there would be a perceptible period of time containing an output of frozen video and muted audio from the first program until valid data from the second program was ready to play. This would be related to the time needed by the application to switch from receiving data from one transponder and then synchronizing the output to the data from the second transponder.
With the above needs as background, the following is an overview of transport stream processing pursuant to MPEG standards.
The MPEG-2 Generic Coding of Moving Pictures and Associated Audio: Systems Recommendation H.222.0 ISO/IEC 13818-1 defines the mechanisms for combining, or multiplexing, several types of multimedia information into one program stream. This standard uses a known method of multiplexing, called packet multiplexing. With packet multiplexing, elementary streams comprising data, video, audio, etc. are interleaved one after the other into a single MPEG-2 stream.
Transport Streams (TSs) are defined for transmission networks that may suffer from occasional transmission errors. The Packetized Elementary Streams (PESs) are further packetized into shorter TS packets of fixed length, e.g., 188 bytes. A major distinction between TS and PES is that the TS can carry several programs. Each TS packet consists of a TS Header, followed optionally by ancillary data called Adaption Field, followed typically by some or all the data from one PES packet. The TS Header consists of a sync byte (0x47), flags, indicators, Packet Identifier (PID), and other information for error detection, timing, etc. According to the MPEG-2 standard, the semantics for the TS include the following:                Sync—byte: (8-bits) a fixed value 0x47;        Transport—error—indicator: (1 bit) for indicating that an uncorrectable bit error exists in the current TS packet;        Payload—unit—start—indicator: (1 bit) for indicating the presence of a new PES packet or a new TS-PSI (program specific information) Section;        Transport—priority: (1-bit) for indicating a higher priority than other packets;        PID: 13-bit packets Ids including values 0 and 1 which are pre-assigned, while values 2 to 15 are reserved. Values 0x0010 to 0x1FFE, may be assigned by the Program Specific Information (PSI) and value 0x1FFF is used to identify MPEG-2 Null packets;        Transport—scrambling—control: (2-bits) for indicating the scrambling mode of the packet payload;        Adaption field control: (2-bits) for indicating the presence of an optional adaptation field prior to the payload;        Continuity—counter: which is a counter provided per PID (e.g., 4-bits) that increments with each non-repeated TS packet having the corresponding PID.        
Each MPEG-2 program stream may be characterized as a data stream (which can contain data originating from a multitude of data sources) encapsulated using MPEG-2 TS packets, with each packet containing a header field with a Packet Identifier (PID). The PID field is used by the transport demultiplexor to “tune” to a particular set of PIDs that correspond to a given program stream. Each program stream must have a set of distinct PIDs (except for PID=0x1fff for the MPEG-2 Null packet).
As an example:                Program Stream 1:<video PID=0x101, audio PID=0x102, secondary audio PID=0x107, 0x1FFF>valid.        Program Steam 2:<video PID=0x101, audio PID=0x200, private data PID=0x107, 0x1FFF>valid.        Program Stream 3:<video PID=0x102, audio PID=0x102, 0x109> invalid (audio and video programs are sharing same PID=0x102).        
As an MPEG-2 transport steam multiplexes several program streams into one single transport, in order to avoid ambiguity at the receiver, it is required that all the PIDs belonging to the transport stream be distinct. Thus, given a set of program streams that need to be multiplexed into a single transport stream, all the PIDs must be distinct (except for the Null packet which can be present in any program stream). In the above example, the PID=0x101 is used (for video programs 1 and 2) is not allowed since it will lead to a conflict error. Therefore, in the example, one of the programs has to re-assign a new PID value to all packets containing PID=0x101 in order to remove the conflict. It is necessary to provide, in a multiplexing technique, a mechanism for eliminating the PID conflict.
One way to solve this problem is a static technique implemented at program stream creation time, which requires the encoder to ensure distinction for all the PIDs for all the program to be multiplexed into a single transport stream. This requires the content provider to encode all material (e.g., movies, documentaries, sports events, news, etc.) with full knowledge of the playing sequence, to avoid PID conflict among the sources.
Another possibility for eliminating the PID conflict is to search all the PIDs for all the program streams that are being multiplexed. If a PID value appears in more than one program stream, then a new value is chosen that is not being used by any of the program streams. However, this process is time consuming and non-efficient because for each PID it is necessary to check all others to see if it is used by another program, the process has to be repeated for all the PIDs for all the programs.
Using the above techniques, a broadcaster is able to ensure that there are no PID conflicts in a given transport stream when it is broadcast. However, as previously mentioned, it is of increasing interest to simultaneously receive multiple transport streams at a set-top-box in order to allow enhanced services. This can be accomplished with multiple, independent transport demultiplexors. Alternatively, the multiple transport streams can be multiplexed into a combined transport stream that is sent to a single transport demultiplexor. However, in providing this multiplexing function at the set-top-box, all of the challenges faced by the broadcaster in preventing PID conflicts are again present.
It would be highly desirable to provide an efficient PID re-mapping mechanism for eliminating the PID conflict in a multiplexed transport system, and moreover, one that is implemented in hardware so the PID re-mapping can be done in real-time.